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Product configuration systems are often based on a variability model. The development of a vari¬ 
ability model is a time consuming and error-prone process. Considering the ongoing development 
of products, the variability model has to be adapted frequently. These changes often lead to mis¬ 
takes, such that some products cannot be derived from the model anymore, that undesired products 
are derivable or that there are contradictions in the variability model. In this paper, we propose an 
approach to discover and to explain contradictions in attributed feature models efficiently in order to 
assist the developer with the correction of mistakes. We use extended feature models with attributes 
and arithmetic constraints, translate them into a constraint satisfaction problem and explore those for 
contradictions. When a contradiction is found, the constraints are searched for a set of contradicting 
relations by the QuickXplain algorithm. 

1 Introduction 

Matys lfT6l describes a product line (PL) as a group of related products which fulfill similar functions, 
complement one another or are destined for the same target group. Variability models are used to support 
the product configuration process and to analyze the variability of the existing PL. In the context of 
software product lines (SPLs) ifTTl . feature models (FMs) Ifl4ll are a widely used formalism for variability 
modeling. Product configuration is an optimization task in order to find the most suitable product that 
meets a set of predetermined requirements and restrictions. The definition of an objective function for 
this optimization in a pure FM, i.e., a feature model without any attributes, can only refer to the section 
of as many or as few features as possible. In attributed feature models (AFMs) 0, where each feature 
can have multiple integer-valued attributes, optimization during product configuration becomes much 
more interesting. In particular, as attributes can have arithmetic constraints between each other which 
need to be satisfied in a configured product. Defining large and complex variability models, such as 
AFMs with integer-valued attributes and arithmetic constraints, is error-prone. Errors in the variability 
model may lead either to an undesired configurable product or to a realizable product which cannot 
be configured. Another type of modeling error is to relate features or attribute values in a wrong way 
which may either lead to a contradiction between the model and the reality or to a contradiction within the 
variability model. Contradictions within the variability model are hard to find and are mostly accidentally 
discovered without tool support. Furthermore, it is a time consuming and difficult task to find the reason 
for such a contradiction manually in order to resolve it. 

To counter this problem, we present an approach to detect contradictions within AFMs in an efficient 
way. We further provide means to explain the cause of the contradiction to support the modeler to build 
a consistent AFM. There has been a lot of work on finding contradictions in the FM community on 
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pure FMs fSj |29l 127, 22' j4|, but to the best of our knowledge there were only suggestions to do this 
on AFMs with integer-valued attributes and general arithmetic constraints. The analysis of AFMs with 
integer-valued attributes and arithmetic constraints is particularly complex 0], since not only attribute- 
value pair s have to be considered, but also arithmetic constraints. The number of products derived from 
the model can change drastically if such arithmetic constraints are involved. We describe how an AFM 
with integer attributes can be translated into a constraint satisfaction problem (CSP) for configuration and 
analyses purposes. We show how the detection of contradictions can be realized efficiently by reducing 
the size of the AFM, by reducing the number of checks and by making the checks themselves more 
efficient. In addition, we present how contradictions within the AFM can be detected automatically. To 
this end, we adapt the QuickXplain algorithm lfl2l [T3 i in order to efficiently find a contradicting set of 
constraints in the CSP. We implement our approach in SWI-Prolog flOll with the library CLP(FD), a 
constraint solver for finite domains written by Triska If24l . This solver provides powerful constraints 
for integer arithmetic, determines and is correct f25l . For evaluation we use a case example from a 
medium-sized mechanical engineering PL with 497 features and 1990 attributes. 

The outline of this paper is as follows: In Section[2| we describe the considered variability model and 
its translation into a CSP. In Section [3} the different kinds of contradictions are defined and an efficient 
approach for their detection is proposed. Afterwards, we describe in Section [4] how the contradicting 
relations can be found and presented to the modeler in a way that helps him to resolve the contradiction. 
A case study for the developed tool support is presented in Section [5] In Section [6} related approaches 
are described, before the paper is summarized in Section [7] 

2 The variability model 

The variability of a PL can be described by a FM. To make optimization possible, each feature may have 
some integer attributes. The variability model we consider in this paper is called AFM @ if it contains 
features with integer-valued attributes and consists of the following two parts: 

• A (graphical) notation which represents the hierarchically arranged set of features and attributes 
with the relationships between parent- and child features called feature-tree. 

• cross-tree constraints (CTCs) that specify conditions, i.e., relations over the integer values of the 
attributes, that a product configuration must satisfy. These are usually written in a textual notation 
in Figure [I] 

As an example, Figure [I] shows a feature-tree with CTCs of a simplified robot PL from a real world AFM 
for configuration purposes. A Robot consists of a Motor, a Tool and an optional Protective-grid. The 
Motor attribute Motor.pwr allows a motor with either 10, 20 or 30 kW driving power. The alternative- 



Figure 1: AFM of a Robot 
























1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 


U. Lesta, I. Schaefer & T. Winkelmann 


33 


Robot = Tool // Mandatory 

Robot = Motor 

Protective_grid = Mounting_set 

Robot = 0 ==> Protective_grid = 0 // Optional 
Protective_grid = 1 ==> Robot = 1 

sum([Mill, Glue, Drill], =, Tool) // Alternative 

Drill = 0 <==> Dr ill : pwr_min = nil // Attribute 

Glue = 0 <==> Glue : pwr_min = nil 

Mill = 0 <==> Mill : pwr_min = nil 

Motor = 0 <==> Motor : pwr = nil 

Tool = 0 <==> Tool : pwr_min = nil 

// Abstract attribute 

element(_, [Drill:pwr.min , Glue:pwr.min , Mill:pwr_min] , Tool:pwr_min) 

Tool:pwr_min \= 20 ==> Mill:pwr_min \= 20 

Tool:pwr_min \= 10 ==> Glue:pwr_min \= 10 

Tool:pwr_min \= 20 ==> Drill:pwr_min \= 20 

// cross-tree - constraints 

Robot = 1 

Motor: pwr >= (Tool : pwr _min) * 110 / 100 
Drill = 1 \/ mill = 1 ==> Protective_grid = 1 


Listing 1: AFM from Figure [I] as constraints 


group Tool can be specialized either as a Drill or a Glue or a Mill tool. Each possible tool defines its 
minimum input power by an attribute pwr_min. The abstract attribute Tool:pwr_min groups the child 
attributes. The optional Protective -grid requires also a Mounting_set. These mandatory feature chains, 
which do not change the variability of the AFM, are typical for real-world configuration models. They 
reflect the hierarchically whole-part relations of a machine. Often, they are extended by attributes like 
price or weight which are summarized up to the root by CTCs for possible optimisation. The CTCs are 
specified in a textual form by the keyword constraint followed by a name and the actual constraint. 
The syntax and semantics of the constraints in this case follow SWI-Prolog iflOl . Feature- and attribute 
names are translated into variables of the constraints. The construct exist requires that the feature 
variable is set to true, while the construct nonexist demands the opposite. 

A FM can be translated, e.g., into propositional logic (SAT solver), description logic, constraint 
logic, binary decision trees 0. The translation of an AFM into a CSP is the most suitable representation 
for product configuration puiposes and analyses of contradictions, because most CSP solvers offer good 
support for optimisation and can handle arithmetic constraints. Also explaining a contradiction in terms 
of constraints is best done in the same language the modeller defines the AFM. A CSP is described by 
Tsang ll26l as a Triple csp = {Z.D,Z ; } where Z is a finite set of variables, D is a set of possible domain 
values for each variable and ^ is a finite, possibly empty, set of constraints which are restricting the 
domain values of the variables. A CSP solver takes a CSP and searches for a possible solution which 
contains assignments for each variable from its corresponding domain which satisfies all constraints. The 
solving process is divided into two substantial steps. The first step tries to reduce the solution space of 
the CSP by value propagation where some, but generally not all, invalid domain values are removed from 
D. In the second step, all remaining variable assignments are explored, mostly by backtracking, to find 
a solution. This step is known as the labeling process of a CSP-Solver. A CSP is called consistent if a 
solution exists, otherwise it is called inconsistent. We translate the AFM into a CSP. The mapping of 
the feature-tree is shown in Tableland is based on the work of John ifTTl . For each feature, a variable 
with the possible domain values 0 and 1 is created where 1 represents the existence of the feature and 0 
its absence. For each attribute of a feature, a variable is generated with the given possible domain values 
of the attribute and an additional nil value. The value nil indicates that no domain value is valid for this 
attribute. In this case, the feature of the attribute must also be absent. This is captured by the constraint 
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P = 0 a = nil which sets the value nil to the attribute variable when its feature does not exist and vice 
versa. Since every value of the attribute can be chosen they are known as an optional attribute values. 

For a mandatory feature relation where 
the feature C is a part of the feature P, 
a constraint P = C is defined. This con¬ 
straint ensures that both features or nei¬ 
ther of them must exist. For an optional 
feature C which may be part of the fea¬ 
ture P, the following constraint is created 
(C = 1 =* P = 1) A (P = 0 =>■ C = 0). This 
constraint ensures that, if the feature C ex¬ 
ists, the feature P must also exist and if P 
does not exist the child feature C cannot 
exist. For an alternative-group where only 
one child feature of P can exist, the con¬ 
straint sum([Ci,C 2 ,...C„],=,P) is added. 
This constraint ensures that the sum of the 
existence variables C\...C„ is equal to the 
existence variables of P. So neither P nor 
any children of P exist or P and only one 
child of P can exist. 

For the parent feature P of an alternative- 
group, an abstract attribute a can be de¬ 
fined if all children C\ ...C n define an at¬ 
tribute a with the same name and type, 
similar to abstract super-classes in OOP. 
The set of possible domain values for the 
abstract attribute a at the feature P is the 
union of all domain values of all attributes 
a from the children C\ ...C n . For the ab¬ 
stract attribute a in Table 1, the domain 
valueswouldbe{l,2,3}. 

Table 1: Mapping graphical AFM elements to a CSP 

This can be expressed by the constraint element(_, [Ci:a,C 2 '.a],P:a). If a domain value is removed 
from the abstract attribute, this value must also be removed from all child attributes. A constraint of the 
form P.a / dv =>■ Cf.a / dv is created for each domain value dv that occurs in the attribute a of C, based 
on John ifTTI . John shows that this translation rules lead to a tree-like CSP in which the nodes represent 
variables and the undirected arcs represent the existence of an constraint between them. Freuder |j9j 
shows that tree-like constraint graphs can be solved without any backtracking. So the CSP obtained by 
translating the feature tree can be solved by arc-consistency lfl5ll propagation mechanism of a solver. 

The CSP generated from the AFM in Figure [l]is shown in Listing [T] Each feature name represents a 
CSP variable. In lines 1 to 3, the constraints express the mandatory features. If Robot exists, Motor and 
Tool must also exist, and if Protective.grid exists, the Mounting_set must be also present. The constraints 
in line 5 and 6 are derived from the optional feature Protective-grid. The sum constraint in line 8 ensures 
that only one Tool is selected, if it exists. In lines 7 to 11, the constraints ensure consistency between the 
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existence of a feature and the attribute values. For the abstract attribute Tool:pwr_min , the constraints in 
lines 13 to 16 are generated. The CTCs are shown in lines 18 to 20. 

3 Contradictions 

The development of an AFM is an error-prone task. Benavides et al. 0 propose the most complete 
collection of analysis tasks we arc aware of up to now. Searching for contradictions in an AFM is one 
of these analysis tasks. It is also called detection of anomalies. There are two kinds of contradictions 
that occur in a variability model: A model contradiction (aka. model anomaly) is a contradiction 
between the semantics of the feature tree and the CTCs (e.g. an optional feature which is present in 
all possible products due to cross-tree-constraints). An inconsistent model (aka. void feature model) 
exists if no product can be derived from the model at all (e.g., a cross-tree constraint requires the absence 
of a full mandatory feature). Model contradictions can be described as properties of the AFM and its 
elements Il23ll . The following properties can be determined automatically because these contradictions 
always consist of at least one cyclic dependency of the relations in the AFM: 

• Void feature model. This property of a FM is true if the FM is inconsistent which means that it 
represents no product at all. 

• Dead feature'. This property is true if a feature cannot be selected in any product, therefore, it 
appears in no product. 

• False optional feature: Th e false optional feature property becomes true if a feature is included in 
all products of the product line despite not being modeled as mandatory. 

In addition, these properties can be adapted to attributes domain values of AFMs aswell. 

• Dead attribute values: This property of a domain value becomes true if the value cannot be as¬ 
signed to its attribute in any product. (E.g., in Figure [T] the domain value 10 cannot be assigned to 
Motor.pwr because a cross-tree constraint requires a minimum motor power of Tool:pwr_min plus 
10 percent). This property is the same as non-attainable domain values introduced by Salinesi and 
Mazo d. 

• False optional attribute values: An attribute value has the property false optional if it is included 
in all products of the product line despite being modeled as an optional attribute. 

The reasons that makes any of the above properties true arc always related to cross-tree constraints. For 
an AFM without cross-tree constraints, none of these properties can be true because the CSP, constructed 
from the feature tree is a tree-like CSP which contains no cyclic dependencies. Imagine a tree where the 
nodes are variables or values of the CSP and the arcs are the relation between them. In this case, a 
solution of the CSP always exists. A contradiction is only possible if the tree becomes a graph by an 
additional relation from a CTC. 

Detection of Contradictions The main operation to detect a contradiction is a method which takes an 
AFM and derives a product from it. In other terms, a constraint solver needs to calculate a solution of 
a CSP which represents the AFM. This is exactly the case for detecting a void feature model. In order 
to detect the other contradictions, we need the possibility to add additional constraints to the AFM, e.g., 
to detect a dead feature, a constraint which selects this feature must be added. For this reason, Trinidad 
Il22i proposes to distinguish between a FM and a stateful feature model (SFM). A SFM can also contain 
additional constraints, corresponding to user decisions and feature selections. A naive approach to find 
contradictions is to check all features and attribute values. After checking the AFM for a solution (no 
void feature model), for each feature the following steps are executed to detect contradictions: 

1. Select a feature. A constraint is created where the variable which represent the feature in the CSP 
is set to 1. This constraint is added to a copy of the FM resulting in a SFM. 
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2. Find a solution. The constraint solver is used to derive a product solution of the SFM. If no 
solution is found, the feature is marked as a dead feature. 

3. If the feature is optional or part of a child in an alternative-group: Deselect this feature. A con¬ 
straint is created where the CSP variable of the feature is set to 0 and the constraint is added to a 
fresh copy of the FM to get a SFM. 

4. Find a solution. If no solution is found for the SFM from the step above, this feature is marked as 
a false optional feature. 

The process to check the attribute values is similar. First all attributes are collected. For each attribute, 
all possible domain values must be checked. So for each domain value, the following steps are executed: 

• Check for a dead attribute value. A constraint is created which sets the attribute to the domain 
value, adds the constraint to a copy of the AFM and searches for a solution. If there is no solution, 
this attribute value is marked as a dead attribute value. 

• Check for a false optional attribute value. A constraint is created where the domain value is 
removed from the attribute and added to a copy of an AFM. If no solution is found, this attribute 
value is a false optional attribute value. 

This approach is inefficient because not all features and attribute values have to be checked. Some 
properties for certain features or attributes cannot be true because these features or attributes are not 
involved in cross-tree constraints. Other properties must not be checked due to the semantics of the 
feature tree. E.g., a full mandatory feature must not be checked for the dead feature property if the 
property void feature model is false. Additionally, some contradictory properties for certain features or 
attributes can be true as a side-effect if this feature or attribute is connected to another feature or attribute 
by a feature-tree or cross-tree constraint for which a contradictory property is true. 

Efficient Contradiction Detection To decrease the computation efforts during the search for contra¬ 
dictions, we reduce the CSP which represents the AFM and propose additional rules to decrease the 
amount of checked features. 

The basic idea is to reduce the variability of the AFM by deleting all features and attributes which 
cannot be part of any contradiction. As a contradiction needs at least a cyclic path of its relations, we 
can safely delete all leaf-features and attributes which are not part of an alternative-group from the AFM 
which do not appear in any cross-tree constraint. Only cross-tree constraints can create cyclic relation 
paths in the AFM. In detail, we remove: (1) Each set of attributes marked as abstract in an alternative- 
group where none of the attributes appears in any cross-tree constraint. (2) Any other attribute which 
does not appear in any cross-tree constraint. (3) The features of an alternative-group if none of the 
features has an attribute or a child-feature and none of them appears in any cross-tree-constraint. (4) And 
any other leaf feature not appearing in any cross-tree constraint. 

The analysis process benefits from the reduced AFM in two ways: (1) Less features and attributes 
have to be checked for a possible contradiction. (2) A smaller CSP can be used in the checks to search 
for a possible product. In addition, the modeler benefits from the reduced AFM because only the root 
of a contradiction is found. Possible aftereffects are not detected, only the head features of mandatory 
feature chains are interesting for contradiction checking. Consider the feature Moundng.set in Figure 
[T] If the feature Protective.grid is a dead feature, it is clear that Mounting_set is also a dead feature. 
Therefore, it is only necessary to find and check the heads of those feature chains. 

Apart from the reduced AFM, there are two more ways to increase the performance of contradiction 
analyses. The first is to investigate how the number of checks for a solution can be reduced since finding 
a solution in a CSP is an expensive task. The second is to improve the solution finding process itself. 
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Reduce Number of Checks While Salinesi and Mazo |[T8l only mention the possibility to reduce the 
amount of solution checks by comparing the set of features to be checked against the features of a derived 
product from a check, we implement this approach and improve it further as follows: 

From the reduced AFM, we collect all optional features and children of an alternative-group from the 
feature-tree into a set of features to be checked. This set is duplicated to a set called check dead for the 
dead feature checks and a set called check_f alse.opt for the false optional feature checks. All features 
of these sets are compared with the features from the derived product after the void feature model check 
of the AFM. A feature from the set check.dead will be removed if it is selected in the product. Features 
from the set check_f alse_opt will be removed if they are not in the product. This halves the amount 
of checks because each feature from the AFM is either selected or deselected in the derived product. 
For each remaining feature of the check_dead set, a dead feature check is performed starting with the 
features from the alternative-groups where only one feature can be selected at a time. Afterwards, the 
features from both sets are compared against the derived product from the dead feature check. If the FM 
contains large alternative-groups, a huge amount of false optional feature checks can be pruned because 
most features of an alternative-group are deselected in a product. 

For further reduction of dead feature checks, we are interested in a derived product that contains as 
many features as possible from the features in the set check_dead. It can be obtained by an explicit 
labeling strategy for the CSP when solving the dead feature check. The variables representing the exis¬ 
tence of the optional features from the check.dead set are labeled with a strategy which tries the highest 
domain values first. This results in a derived product where the maximum of optional features can be 
removed from the set check.dead. During th e false optional feature checks, the labeling strategy tries 
the smallest domain values first for the CSP variables representing the optional features. During the dead 
feature checks, the labeling strategy for the optional features can be switched to the false optional fea¬ 
ture check strategy if all optional features are removed from the set check_dead. Then, the dead feature 
checks derive products which contain the minimum number of optional features which are removed from 
the check_f alse_opt set. Depending on the amount of features in alternative-groups mostly the set of 
check_f alse.opt features is empty when all dead feature checks are done. 

Reduce Checking Efforts The second way to increase performance is to speed up the CSP solver in 
finding a solution. In general, finding a solution of a CSP is a NP-complete problem ll26l . With the 
reduced AFM, we decrease space, not the time complexity which comes with the cross-tree-constraints. 
This leads to less propagation steps in the CSP-Solver in the labeling process. In practical examples 
the performance gain from using the reduced AFM is about linear to the reduced size, as the amount 
of propagation steps are nearly linear to the amount of constraints generated from the feature-tree. The 
labeling options of the CSP-solver are the key to speed up solution finding. Most solvers offer the 
possibility to define the order of the variables, the domain value order and the branching strategy for 
the labeling process. Unfortunately, the fastest labeling strategy depends on the specific problem. In 
general, it is a good idea to store the labeling options within the AFM. As a starting point, we use 
an order where the variable with the smallest domain is labeled first. Then, the detection of infeasible 
values happens at an early stage. Additionally, for variables representing the existence of the features, an 
order is chosen where the variable participating in most constraints are labeled first with an enumerating 
branching strategy. For attribute variables, a bisection method as a branching strategy is chosen. These 
options are problem-specific and can change the performance heavily. 

4 Explaining Contradictions 

After detecting a void feature model or an other property indicating a contradiction, the modeler needs 
a clue to change this mistake in the variability model. The essential task for removal of contradictions 
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within the AFM is changing relationships between features or attribute values. Therefore, the contra¬ 
dicting relations must be detected and shown to the modeler. Afterwards the modeler must decide which 
relation needs to be changed in order to resolve the contradiction. 

Consider for example the AFM 
shown in Figure [TJ if the modeler 
removes the feature Glue from the 
alternative-group Tool, the feature 
Protective -grid becomes a false 
Listing 2: Defiant constraints for the false optional feature optional feature. Listing [2] shows 

Protective-grid if the feature Glue is removed the contradicting constraints for 

the false optional feature Protective-grid in this AFM. Line 1 shows the constraint to check the false 
optional feature property for the feature Protective-grid. The feature Protective-grid is disabled and the 
CSP becomes inconsistent which means that the CSP has no solution (the AFM is a void feature model). 
The constraint in line 2 expresses that a robot exists and the constraint in line 3 requires the existence of 
the alternative-group Tool if a robot exists. In line 4, the constraint determined that one feature from the 
alternative-group Tool must exist. The CTC in line 5 requires the feature Protective-grid if the feature 
Mill or Drill exists. Hence, the selection of feature Protective-grid contradicts the constraint in line 1. 

For a given inconsistent CSP, a simple approach to find the contradicting constraints is to check all 
possible subsets of constraint combinations for consistency and select the smallest inconsistent set. The 
effort for this, however, is exponential. In real world scenarios, the modeler does not need the smallest 
conflict set. An arbitrary conflict set, which has no smaller subset of conflicting constraints, contains in 
most cases enough information for the modeler to solve the conflict. 

QuickXPlain Junker developed the QuickXPlain algorithm lfT2l [13 3 which calculates an inconsistent 
set of constraints for a given inconsistent CSP. The number of consistency checks for the QuickXPlain 
algorithm is 0(n,k ) = 2k* logzin/k) + 2k lfl3l . with n the number of all constraints and k the number 
of constraints in the resulting conflict set. The number of constraints in the conflict set k in relation to 
the number of all constraints n has a vital impact on the number of consistency checks. The conflict set 
computed by QuickXPlain is one of possibly many, whereas the simple approach described above finds 
the smallest conflict set, but with 0(n ) = 2" consistency checks. 

Modularization of AFM Finding an explanation for a contradiction is a time consuming task. We 
decrease the computation efforts by reducing the number of constraints to check and constraints in the 
conflict set. The basic idea is to call the QuickXPlain algorithm twice in a cascading way. Therefore, we 
group the constraints representing the AFM into large conjunctions of constraints and call the QuickX¬ 
Plain algorithm on this constraint-groups. Afterwards, we split up the constraint-groups from the result¬ 
ing conflict set back into their native constraints and run QuickXPlain again on this set of constraints. 
All constraint-groups which are not part of the initial conflict found by the first call of QuickXPlain can 
be ignored. This decrease the number of constraints for the second computation. The main challenge is 
using a good heuristic to build the constraint-groups for the first call of QuickXPlain. A good gouping 
has a small amount of constraint-groups and leads to small conflict set which contains in the best case 
with one constraint-group. 

During development the modeler maps the structure of the PL into the AFM similar to multi software 
product lines j6[. Thereby, the modeler encapsulates subunits, respectively assembly units, of the PL into 
AFM-modules. That reflect the structure of the PL into the AFM for separation of concerns and reuse. 
This existing module structure can be exploited as a good heuristic for grouping of the constraints for 
efficient explanation of contradictions. 
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Table 2: Amount of checks and execution times for finding explanations 


All constraints of a module can be consolidated to one conjunctive constraint. It reduces the number 
of constraints for the first call of QuickXPlain to the number of modules. Furthermore, the resulting 
conflict set is also small because most conflicts occur within a single module or between two modules. 
This grouping with cascading calls of the QuickXPlain algorithm leads to ca. 10 times faster computation 
for the explaining conflict set (see Section [5]). 

If a module structure is not available, another idea to group the constraints is finding all clusters 
of connected CTCs and add all generated constraints from the feature-tree bottom up to these clusters. 
Other groupings, e.g., by the type of the relation in the feature-tree give a performance gain of less than 
10 percent. The evaluation of different grouping approaches is left future work. 

Implementation Details of a modularized AFM In order to build an AFM-module, all external de¬ 
pendencies of the module can be added as attributes in the module’s root feature. This can be done, e.g., 
by adding CTCs between the root attribute and the features or attributes internal to the module. In our 
approach, we introduce feature and attribute references at the root feature which behave like the original 
feature or attribute, but are accessible from other modules via the module’s root feature. The module’s 
root feature becomes an interface of the module, containing all external dependencies between the fea¬ 
tures and attributes of the used module and of a super-ordinate module. For reusable modules, we support 
the marking of features and attribute values as false optional or dead by a ’pragma’ directive. This is 
necessary because when using one module multiple times in a greater AFM, the modeler does some 
pre-configuration of the generic module with cross-tree constraints which leads to model contradictions. 
These intentional contradictions are ignored at the stage of contradiction detection. 

5 Case Study and Tool Support 

The approach developed in this paper is implemented in SWI-Prolog. The translation of the feature- 
tree into constraints is written in constraint handling rules (CHR) llT9l and SWI-Prolog. As case study 
for evaluating our approach, we use a configuration model for generating quotes for a medium-sized 
mechanical engineering application. This model contains 497 features with 1990 attributes of which 237 
are optional features, 49 alternative-groups and 256 cross-tree-constraints. The feature-tree results in 
3402 constraints in the CSP. Using this case study, we evaluate our proposed approach for detecting and 
explaining contradictions. First, we show that the reduction of the AFM leads to reduced computation 
times, both for detecting and explaining contradictions. Second, we show that the cascaded approach for 
explaining contradictions also decreases computation times. Randomly generated models are not suitable 
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for evaluation puiposes as randomly generated constraints typically do not reflect realistic relationships. 

The reduced AFM with the process described in Section[3]is about 50 percent smaller. It contains 222 
features with 712 attributes, 90 optional features, 35 alternative-groups and 1161 generated constraints. 
In the AFM, there are 396 features to check for the false optional property (237 optional features plus 
159 children from the alternative-groups) and 497 features to check for the dead feature property. With 
the efficient approach presented in Section[3j we need only 48 consistency checks for the remaining 161 
features to discover the contradictions. Thereby, each consistency check is twice as fast because of the 
smaller amount of constraints to propagate. Hence, the overall performance improvement for detecting 
contradictions for the reduced AFM, compared with the native approach, is round a factor of 32. 

Table [2] shows the amount of consistency checks and the computation time which is necessary to find 
a conflict set of constraints to explain a contradiction property. The execution times are determined on a 
Laptop with an Intel dual core processor T7500 with 2200 MHz and 3 GByte RAM by the SWI-Prolog 
predicate time/1 in seconds. Each line shows different scenarios, which descibe the effort to explain a 
model contradiction in the AFM. In column 2, the number of constraints in each of the conflict sets is 
listed. The block ’simple search’ shows, for a single QuickXPlain call, the computation time in seconds 
and the number of consistency checks. Therein, the first two columns are for the full AFM and the second 
for the reduced AFM. In the second block ’cascading search’ the time and checks are listed for cascaded 
QuickXPlain calls for the AFM and the reduced AFM. In a cascading search, the constraints are grouped 
by the module structure for the first call (comp. Sect. [4]). These results show that our approach also 
improves the computation times for explaining contradictions. The best improvements are obtained with 
the cascading search. If we apply the cascaded search, the additional reduction of the AFM does not 
matter. If, however, the reduced AFM is used in a single search, the time required for explaining the 
contradiction is improved by about three times. 

6 Related Work 

The analysis of FMs is an active area of research El HB1- Most approaches consider pure feature mod¬ 
els without attributes or just mention that their approach can be adapted to AFMs. Benavides |[4] et 
al. present a classification of different approaches for the analysis of FMs. They mention numerous 
proposals to detect void feature models. Fewer approaches consider the detection of dead features, and 
even less deal with the detection of false optional features. In this survey only Trinidad 1221 presents an 
approach on how to find and explain all the above mentioned anomalies in a pure FM. For this he used 
a constraint solver and Reiter’s theory of diagnosis. In contrast to our work, Trinidad does not consider 
integer-valued attributes and general arithmetic constraints. There are two approaches which deal with 
detecting and explaining contradictions in AFMs that are related to our work. For explaining contradic¬ 
tions in an AFM, Zaid et al. l28l propose an approach based on description logic. This approach covers 
detection and explaination of dead features using the Pellet Reasoner Kill . However, in contrast to our 
work, they only use constraints on attribute values containing smaller-, greater- or equal-relations and 
no general arithmetic constraints as we do. Osman et al. Q detect and explain anomalies in a FM by a 
knowledge-based method using propositional logic. He extends a FM by so called variation points. The 
variation points are cardinalities which allow a more complex grouping of features. However, there is no 
possibility to encode attributes with the possibility to express arithmetic cross-tree constraints. 

Felfernig et al. (8l also use constraint sets to find inconsistencies in FMs which is very similar to our 
approach, but also lacks the handling of arithmetic constraints and integer-attributes. Zhang et al. ll29l in¬ 
troduced refinement paths, which decreases the number of checks needed by a satisfiability (SAT) solver. 
But they only do this on a simplied version of pure FMs. A more practical approach is studied by Xiong 
et al. fi27ll . where they provide a list of solutions on encountered configuration problems in the eCos 
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configurator. The eCos configurator also contains numeric attributes in its configuration domain. Their 
approach aims to support customers during their configuration and not the developer during modeling 
the AFM. There are other tools and languages which are designed for modeling and configuration of 
AFMs. For instance, TVL a text-based formal language for modeling AFMs designed by Classen et 
al. J51. TVL contains structuring mechanisms for FMs, such as user-defined types or imports and AFMs 
with artihmetic constraints. Unfortunately checking such AFMs is still under construction and currently 
supports only pure FMs. Similarly, FAMILIAR by Acher et al. HI is a textual language for represent¬ 
ing FMs which allows (amongst other operations) im-/ex-porting, (de-)composing, slicing and diffing of 
(multiple) FMs. FAMILIAR supports reasoning about FMs, but still only FMs without attributes. The 
SPLConqueror from Siegmund et al. l20l uses attributed FMs and optimization functions to help stake¬ 
holders during the configuration. They also describe the use of constraints for feature restriction, but it is 
unclear how errors in the model can be detected and explained to the modeler. Another approach is the 
Clafer modeling language from GSD Lab at the University of WaterlocQ It is a DSL for modeling FMs 
with attributes and constraints. They support detection of void FMs, but direct support is still missing 
to find e.g. dead attribute values. Summarizing, none of the existing approaches (cf. 101) supports the 
detection and explanation of contradictions, in the sense of all of the above mentioned properties, in 
AFM with integer-value attributes and arithmetic constraints. 

7 Conclusion 

In this paper, we presented an approach for the detection and explanation of contradictions in AFMs with 
integer-values attributes and general arithmetic constraints. Based on the translation of the feature-tree 
into a CSP, we presented how the labeling process of a constraint solver can be adapted for the efficient 
detection of contradictions. The QuickXPlain algorithm 1021 031 is used for computing a conflict set 
of contradicting constraints which explains the reason of a contradiction. For larger AFMs, we used a 
modularization concept similar to MSPLs to improve the computation time by cascading calls of Quick¬ 
XPlain. For future work, we will further investigate possible tool integrations, heuristics to determine 
possible clusters of constraints in order to speed up the time for explaining contradictions. Additionally 
we want to compare our approach with an implementation of the Felfering et al. 0 algorithm FAST- 
DIAG combined with a diagnosis model. 
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